SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Revue de code</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Revue de code</span></h1>

</header>

</div>

<p>La <b>revue de code</b> (calque de l'anglais <i><span class="lang-en" lang="en">code review</span></i>), ou <b>révision de code</b><sup id="cite_ref-GDT_1-0" class="reference"><a href="#cite_note-GDT-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>, est l'examen systématique du <a href="Code_source" title="Code source">code source</a> d'un logiciel.

</p><p>Cet examen peut être comparé à la critique effectuée par un <a href="Comit%C3%A9_de_lecture" class="mw-redirect" title="Comité de lecture">comité de lecture</a>, dont le but est de trouver des <a href="Bug_informatique" class="mw-redirect" title="Bug informatique">bugs</a> ou des vulnérabilités potentielles ou de corriger des erreurs de conception afin d'améliorer la qualité, la maintenabilité et la sécurité du logiciel.

</p><p>Une revue de code peut s'appuyer sur la vérification (manuelle ou automatisée) du respect d'un ensemble de règles de programmation.

</p><p>Si la revue de code est depuis longtemps reconnue comme un moyen performant d'améliorer la qualité du logiciel, les organisations qui ont mis en place cette démarche systématique ont longtemps été minoritaires<sup id="cite_ref-7th_2-0" class="reference"><a href="#cite_note-7th-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>. La revue de code tend à devenir une étape à part entière dans le développement logiciel, en particulier dans les <a href="M%C3%A9thode_agile" title="Méthode agile">méthodes agiles</a> comme l'<a href="Extreme_programming" title="Extreme programming">extreme programming</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Objectifs">Objectifs</h2></div>

<p>La révision de code vise plusieurs objectifs :

</p>

<ul><li>améliorer la qualité du code <sup id="cite_ref-aa10_3-0" class="reference"><a href="#cite_note-aa10-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> ;</li>

<li>favoriser la collaboration, le travail en équipe<sup id="cite_ref-aa10_3-1" class="reference"><a href="#cite_note-aa10-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> (appropriation du code par l’équipe) ;</li>

<li>appliquer un standard <sup id="cite_ref-aa10_3-2" class="reference"><a href="#cite_note-aa10-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> ;</li>

<li>détecter et corriger les défauts (bugs mais aussi lisibilité) au plus tôt dans le cycle de vie du code pour économiser les coûts<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> ;</li>

<li>former des développeurs.</li></ul>

<p><a href="Hewlett-Packard" title="Hewlett-Packard">Hewlett-Packard</a> valorise le retour sur investissement d'une revue de code à 10 pour 1<sup id="cite_ref-7th_2-1" class="reference"><a href="#cite_note-7th-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Revue_et_tests">Revue et tests</h3></div>

<p>La revue est environ 2 à 4 fois plus rapide que le test<sup id="cite_ref-7th_2-2" class="reference"><a href="#cite_note-7th-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> et offre un meilleur taux de détection des défauts : <a href="Test_unitaire" title="Test unitaire">tests unitaires</a> 25 %, <a href="Test_d'int%C3%A9gration" title="Test d'intégration">tests d'intégration</a> 45 %, revue de conception 55 %, revue de code 60 %<sup id="cite_ref-ja06_5-0" class="reference"><a href="#cite_note-ja06-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>.

</p><p>Mais la revue ne détecte pas les mêmes défauts que le test<sup id="cite_ref-7th_2-3" class="reference"><a href="#cite_note-7th-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Pratiques">Pratiques</h2></div>

<p>La revue de code peut prendre différentes formes, plus ou moins formelles. Il faut choisir le modèle le mieux adapté en fonction de la tolérance au risque du code audité<sup id="cite_ref-7th_2-4" class="reference"><a href="#cite_note-7th-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Inspection_formelle">Inspection formelle</h3></div>

<p>Michael Fagan, cadre chez IBM, a formalisé en 1976 une méthode d'inspection du code qui se base sur la convocation de plusieurs réunions d'audit <sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup>. Assez lourde, elle requiert en moyenne neuf heures-hommes pour 200 lignes de codes<sup id="cite_ref-jc2_7-0" class="reference"><a href="#cite_note-jc2-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>, elle est difficile à systématiser pour l'ensemble du code.

</p><p><a href="Tom_Gilb" title="Tom Gilb">Tom Gilb</a> et Dorothy Graham ont développé une autre méthode d'inspection assez répandue également<sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Notification_par_email">Notification par email</h3></div>

<p>Le système de <a href="Gestion_de_versions" title="Gestion de versions">gestion de versions</a> peut être configuré pour envoyer un email décrivant chacune des modifications apportées à l'arborescence des sources. Les autres développeurs de l'équipe ont alors l'opportunité d'examiner ces changements.

</p><p>Cette méthode pose des problèmes d'<a href="Assurance_qualit%C3%A9" title="Assurance qualité">assurance qualité</a> : comment savoir si une modification a bien été revue, si les critiques ont été prises en compte…<sup id="cite_ref-jc2_7-1" class="reference"><a href="#cite_note-jc2-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Analyse_par-dessus_l'épaule"><span id="Analyse_par-dessus_l.27.C3.A9paule"></span>Analyse par-dessus l'épaule</h3></div>

<p>L'analyse par-dessus l'épaule (<i>over the shoulder review</i>) est une méthode informelle : l'auteur du code pilote la revue en présentant au relecteur les modifications qu'il a effectuées dans le code source.

</p><p>Elle a l'avantage d'être simple et rapide à réaliser. L'un de ses inconvénients est que, puisque c'est l'auteur qui pilote la revue, il peut manquer un effet de bord qu'il n'avait pas déjà remarqué au moment de l'écriture<sup id="cite_ref-jc3_9-0" class="reference"><a href="#cite_note-jc3-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Programmation_en_binôme"><span id="Programmation_en_bin.C3.B4me"></span>Programmation en binôme</h3></div>

<p>L'efficacité comparée de la programmation en binôme avec les autres méthodes de revue de code reste une question assez controversée. Il est par exemple possible que le binôme ne possède pas un recul suffisant sur le code<sup id="cite_ref-jc3_9-1" class="reference"><a href="#cite_note-jc3-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Utilisation_d'un_outil_dédié"><span id="Utilisation_d.27un_outil_d.C3.A9di.C3.A9"></span>Utilisation d'un outil dédié</h3></div>

<p>Il existe des logiciels permettant d'assister la revue de code<sup id="cite_ref-jc2_7-2" class="reference"><a href="#cite_note-jc2-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>:

</p>

<ul><li>collecte et présentation des modifications apportées aux fichiers sources qui nécessitent une relecture</li>

<li>gestion du <a href="Workflow" title="Workflow">workflow</a> : la relecture devient une étape de l'intégration continue</li>

<li>annotation des défauts et commentaires issus de la relecture, suivi des corrections de ces défauts</li>

<li>statistiques et <a href="M%C3%A9trique_(logiciel)" title="Métrique (logiciel)">métriques</a> (vitesse de relecture, taux de détection des défauts…)</li></ul>

<p>Quelques logiciels libres:

</p>

<ul><li>Review Board : <a href="Logiciel_libre" title="Logiciel libre">logiciel libre</a> à <a href="Interface_web" title="Interface web">interface web</a> créé par <a href="VMware" title="VMware">VMware</a>.</li>

<li>Agile Review : <a href="Plugin" title="Plugin">plugin</a> libre pour <a href="Eclipse_(logiciel)" class="mw-redirect" title="Eclipse (logiciel)">Eclipse</a>.</li>

<li>Crew : <a href="Logiciel_libre" title="Logiciel libre">logiciel libre</a> de revue de code pour les projets Git.</li>

<li>Rietveld : développé pour <a href="Google" title="Google">Google</a> par <a href="Guido_van_Rossum" title="Guido van Rossum">Guido van Rossum</a>.</li>

<li>CodeStriker.</li>

<li>JCR : Java Code Reviewer.</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Analyse_statique">Analyse statique</h3></div>

<p>L'<a href="Analyse_statique_de_programmes" title="Analyse statique de programmes">analyse statique de programmes</a> est l'utilisation d'outil comme <a href="Lint_(logiciel)" title="Lint (logiciel)">lint</a> et ses successeurs pour vérifier le respect d'un ensemble de <a href="R%C3%A8gles_de_codage" title="Règles de codage">règles de programmation</a>. L’analyse statique permet d'automatiser (systématiser) certains contrôles (complexité du code, respect de règles de codage…) mais ne permet pas de vérifier certains points plus abstraits (réutilisabilité, efficience, respect du cahier des charges…) qui nécessitent une relecture manuelle.

</p><p>L'analyse statique et la revue par les pairs sont donc complémentaires, permettant d'étendre qualitativement et quantitativement la revue du code. L'outil d'analyse statique permet notamment de se décharger des vérifications de détails et favorise une vision plus globale du système étudié lors de la revue de code.

</p>

<div class="mw-heading mw-heading3"><h3 id="Définition_de_règles_de_codage"><span id="D.C3.A9finition_de_r.C3.A8gles_de_codage"></span>Définition de règles de codage</h3></div>

<div class="mw-heading mw-heading3"><h3 id="Checklist">Checklist</h3></div>

<p>Une <a href="Checklist" class="mw-redirect" title="Checklist">checklist</a> est un document qui synthétise les points à vérifier prioritairement pendant la revue de code.

</p><p>Une check-list ne devrait pas contenir plus de dix items, limite de ce qu'un humain normal peut mémoriser<sup id="cite_ref-jc6_10-0" class="reference"><a href="#cite_note-jc6-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>. Il convient donc de :

</p>

<ul><li>supprimer les questions triviales du type "le code est-il correctement commenté" ou "le code répond-il au besoin ?"<sup id="cite_ref-jc6_10-1" class="reference"><a href="#cite_note-jc6-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup></li>

<li>utiliser un outil d'analyse statique pour automatiser tout ce qui peut l'être (<a href="Mise_en_page" title="Mise en page">mise en page</a>, <a href="Convention_de_nommage" title="Convention de nommage">convention de nommage</a>…)<sup id="cite_ref-jc6_10-2" class="reference"><a href="#cite_note-jc6-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup></li></ul>

<p>Les items ne devraient concerner que des choses qui sont souvent oubliées : par exemple "vérifier que la méthode libère proprement les ressources pour tous les cas de retour d'erreur"<sup id="cite_ref-jc6_10-3" class="reference"><a href="#cite_note-jc6-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>. On peut pour cela analyser les 100 ou 200 dernières corrections de bugs pour trouver les causes d'erreurs les plus fréquentes, en faire des items de check-list <sup id="cite_ref-jc6_10-4" class="reference"><a href="#cite_note-jc6-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>.

</p><p>Il sera alors intéressant de classer les nouveaux bugs par items de check-list (en n'oubliant pas une catégorie "aucun de ces items"). Quand un item de la check-list ne contiendra presque plus de bugs (parce qu'une stratégie pour éviter ce problème aura émergé), il sera temps de remplacer cet item par la cause d'erreur la plus fréquente dans la catégorie "aucun de ces items"<sup id="cite_ref-jc6_10-5" class="reference"><a href="#cite_note-jc6-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Autorelecture">Autorelecture</h3></div>

<p>L'autorelecture ou revue personnelle du code consiste pour un développeur à utiliser des méthodes de la revue de code (notamment une check-list) sur sa production logicielle pour détecter et en corriger les défauts<sup id="cite_ref-11" class="reference"><a href="#cite_note-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>.

</p><p>Une étude réalisée à Cisco a montré que les revues qui avaient été préparées par l'auteur (annotation des modifications réalisées dans le code source) retournaient beaucoup moins de défauts<sup id="cite_ref-jc4_12-0" class="reference"><a href="#cite_note-jc4-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup>. Deux hypothèses ont été avancées :

</p>

<ul><li>pessimiste : les annotations induisent la relecture et stérilisent son effet<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup></li>

<li>optimiste : pendant la phase de préparation, l'auteur est amené à relire son code et corrige de lui-même les principaux défauts</li></ul>

<p>Cette étude indique privilégier l'hypothèse optimiste<sup id="cite_ref-14" class="reference"><a href="#cite_note-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Intégration_continue"><span id="Int.C3.A9gration_continue"></span>Intégration continue</h3></div>

<p>L'<a href="Int%C3%A9gration_continue" title="Intégration continue">intégration continue</a> peut systématiser une étape d'analyse statique et/ou de revue par les pairs pour tout nouveau code intégré <sup id="cite_ref-aa10_3-3" class="reference"><a href="#cite_note-aa10-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Savoir_être"><span id="Savoir_.C3.AAtre"></span>Savoir être</h3></div>

<p>L'équipe doit développer une culture de partage du code source, encourager les discussions sur le code. Les gens sont peu enclins à prendre du temps pour comprendre le fonctionnement d'un code trop complexe, donc les retours seront très généraux dans ce cas<sup id="cite_ref-ja07_15-0" class="reference"><a href="#cite_note-ja07-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup>.

</p><p>Il est difficile pour un salarié de dire à son chef qu'un de ses collègues a fait un mauvais travail<sup id="cite_ref-ja07_15-1" class="reference"><a href="#cite_note-ja07-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup>. Le management doit donc développer un climat favorable à la détection des défauts : les bugs sont un processus normal, pas une faute individuelle. Il convient de ne pas culpabiliser mais de mettre par exemple l'accent sur le travail d'équipe : ce qui compte c'est la qualité finale du logiciel.

</p><p>Les développeurs doivent apprendre à maitriser leur égo, faire la distinction entre critique du code et critique personnelle. Il faut prendre en compte les personnes qui ne veulent pas montrer leur travail<sup id="cite_ref-7th_2-5" class="reference"><a href="#cite_note-7th-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>.

</p><p>Il faut aussi convaincre la direction de l'intérêt d'allouer des ressources à la relecture<sup id="cite_ref-7th_2-6" class="reference"><a href="#cite_note-7th-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Métriques"><span id="M.C3.A9triques"></span>Métriques</h3></div>

<p>Les métriques permettent de mesurer l'efficacité de la revue.

</p><p>Métriques possibles<sup id="cite_ref-16" class="reference"><a href="#cite_note-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup> :

</p>

<ul><li>nombre de lignes de code examinées</li>

<li>nombre de défauts trouvés, leur criticité</li>

<li>ressources (heure.homme consacrée à la revue, à sa préparation, au traitement des défauts)</li></ul>

<p>Ce qui permet de calculer par exemple la densité de défaut par <a href="Ligne_de_code" title="Ligne de code">ligne de code</a>, la vitesse moyenne d'inspection d'une ligne de code ou le temps de découverte d'un défaut.

</p><p>Une mesure à large échelle menée chez Cisco a montré que<sup id="cite_ref-jc4_12-1" class="reference"><a href="#cite_note-jc4-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup> :

</p>

<ul><li>limiter le nombre de lignes par revue : le nombre de défauts trouvés diminue fortement au-dessus d'un certain seuil. Chaque revue ne devrait concerner optimalement que 200 lignes, 400 au maximum</li>

<li>vitesse limite de 400 à 500 lignes de code par heure</li>

<li>une heure maximum par revue</li>

<li>un relecteur trouve en moyenne quinze défauts par heure</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Références"><span id="R.C3.A9f.C3.A9rences"></span>Références</h2></div>

<li id="cite_note-GDT-1"><span class="mw-cite-backlink"><a href="#cite_ref-GDT_1-0">↑</a> </span><span class="reference-text"><span class="ouvrage">« <a rel="nofollow" class="external text" href="https://vitrinelinguistique.oqlf.gouv.qc.ca/redirection/ficheuid/26529106"><cite style="font-style:normal;">revue de code</cite></a> », <i><a href="Grand_Dictionnaire_terminologique" title="Grand Dictionnaire terminologique">Grand Dictionnaire terminologique</a></i>, <a href="Office_qu%C3%A9b%C3%A9cois_de_la_langue_fran%C3%A7aise" title="Office québécois de la langue française">Office québécois de la langue française</a> <small style="line-height:1em;">(consulté le <time class="nowrap" datetime="2020-12-11" data-sort-value="2020-12-11">11 décembre 2020</time>)</small></span>.</span>

</li>

<li id="cite_note-7th-2"><span class="reference-text"><a rel="nofollow" class="external text" href="http://www.processimpact.com/articles/seven_truths.html"><i>Seven Truths About Peer Reviews</i></a> Karl E. Wiegers.</span>

</li>

<li id="cite_note-aa10-3"><span class="reference-text"><a rel="nofollow" class="external text" href="http://blog.valiantys.com/fr/techno/revue-de-code-pour-les-equipes"><i>Revue de code pour les équipes trop occupées</i></a>, Alexandre Alquier 27 juillet 2010</span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a> </span><span class="reference-text"><a rel="nofollow" class="external text" href="https://www.laboiteaprog.com/2009/05/revue-de-code-peer-code-review.html"><i>Revue de code, Peer Code review</i></a>, Marc Collin</span>

</li>

<li id="cite_note-ja06-5"><span class="mw-cite-backlink"><a href="#cite_ref-ja06_5-0">↑</a> </span><span class="reference-text"><a rel="nofollow" class="external text" href="http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html"><i>Code Reviews: Just Do It</i></a> Jeff Atwood 21 janvier 2006</span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a> </span><span class="reference-text"><i>Design and Code Inspections to Reduce Errors in Program Development</i> M.Fagan, IBM Systems Journal, Vol. 15, No. 3 (1976), <abbr class="abbr" title="pages">p.</abbr> <span class="nowrap">182-211</span> </span>

</li>

<li id="cite_note-jc2-7"><span class="reference-text"><a rel="nofollow" class="external text" href="https://support.smartbear.com/resources/cc/Episode_2_WhyCodeInspectionsFail.pdf"><i>Lightweight Code Review Episode 2: Why Code Inspections Fail</i></a>, Jason Cohen</span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a> </span><span class="reference-text"><i>Software Inspection</i> Tom Gilb et Dorothy Graham 1993, <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">0201631814</span>)</small></span>

</li>

<li id="cite_note-jc3-9"><span class="reference-text"><a rel="nofollow" class="external text" href="https://support.smartbear.com/resources/cc/Episode_3_ProsAndConsOfFourKindsOfCodeReview.pdf"><i>Lightweight Code Review Episode 3: Pros and Cons of Four Kinds of Code Review</i></a>, Jason Cohen</span>

</li>

<li id="cite_note-jc6-10"><span class="reference-text"><a rel="nofollow" class="external text" href="https://support.smartbear.com/resources/cc/Episode_6_Checklists-YouBuildMeUpJustToKnockMeDown.pdf"><i>Lightweight Code Review Episode 6: Checklists - You build me up just to knock me down</i></a>, Jason Cohen</span>

</li>

<li id="cite_note-11"><span class="mw-cite-backlink"><a href="#cite_ref-11">↑</a> </span><span class="reference-text"><a rel="nofollow" class="external text" href="http://profs.etsmtl.ca/claporte/VSE/Trousses/Revue%20personnelle_Trousse_Francais.doc"><i>Trousse pour une revue personnelle, version 1</i></a></span>

</li>

<li id="cite_note-jc4-12"><span class="reference-text"><a rel="nofollow" class="external text" href="https://support.smartbear.com/resources/cc/Episode_4_TheLargestCaseStudyOfCodeReviewEver.pdf"><i>Lightweight Code Review Episode 4: The Largest Case Study of Code Review, Ever</i></a> Jason Cohen</span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><a href="#cite_ref-13">↑</a> </span><span class="reference-text"><a rel="nofollow" class="external text" href="http://mikeconley.ca/blog/2010/02/07/the-importance-of-first-impressions-how-theatre-criticism-migh-inform-peer-code-review/"><i>The Importance of First Impressions: How Theatre Criticism Might Inform Peer Code Review</i></a> Mike Conley 7 février 2010</span>

</li>

<li id="cite_note-14"><span class="mw-cite-backlink"><a href="#cite_ref-14">↑</a> </span><span class="reference-text"><a rel="nofollow" class="external text" href="https://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-Review.pdf">SmartBear study at Cisco</a>, <abbr class="abbr" title="page">p.</abbr> 4. "We took a random sample of 300 reviews to investigate, and the evidence definitively showed that the reviewers were indeed carefully reviewing the code – there were just fewer bugs."</span>

</li>

<li id="cite_note-ja07-15"><span class="reference-text"><a rel="nofollow" class="external text" href="http://www.codinghorror.com/blog/2007/11/pair-programming-vs-code-reviews.html"><i>Pair Programming vs. Code Reviews</i></a>, Jeff Atwood 18 novembre 2007</span>

</li>

<li id="cite_note-16"><span class="mw-cite-backlink"><a href="#cite_ref-16">↑</a> </span><span class="reference-text"><a rel="nofollow" class="external text" href="http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=3526&ObjectType=ARTCOL"><i>Do Your Inspections Work?</i></a> Karl Wiegers</span>

</li>

</ol></div>

<p><br>

</p>

</div>

<ul id="bandeau-portail" class="bandeau-portail"><li><span class="bandeau-portail-element"><span class="bandeau-portail-icone"><span class="noviewer" typeof="mw:File"></span></span> <span class="bandeau-portail-texte">Portail de la programmation informatique</span> </span></li> </ul></div><div><div class="zim-footer">

Cet article est issu de <a class="external text" title="Dernière modification le 2023-11-12" href="https://fr.wikipedia.org/wiki/?title=Revue_de_code&oldid=209566504">Wikipédia</a>. Sauf mention contraire, le texte est disponible sous <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.fr">Creative Commons Attribution-Share Alike 4.0</a>. Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.

</div>

</div></div>

</div>

</main>

</div>

</body></html>